Инструкция по настройке двусторонних доверительных отношений между MS AD и ALD Pro

Благодаря внедрению ряда решений, включая глобальный каталог ALD Pro, есть возможность настраивать двусторонние доверительные отношения. В отличие от MS AD, в ALD Pro направления доверия MS AD → ALD Pro и ALD Pro → MS AD реализованы разными механизмами.

Двусторонние доверительные отношения, предоставляют возможность общаться доменам ALD Pro и MS AD, решая ряд важных задач:

  • Авторизация пользователей доверенных доменах на рабочих станциях;

  • Доступ к сетевым ресурсам пользователей доверенного домена (веб сервер, файловый сервер, базы данных и т.д.);

  • Разграничение доступа к ресурсам доверенных доменов.

Как работают доверительные отношения MS AD и ALD Pro

Технические требования

Версии Windows Server работающие с глобальным каталогом ALD Pro

browse.dat Файл в директории /var/lib/samba в Samba используется для хранения информации о браузере (Browser Information). Этот файл содержит данные о доступных ресурсах и службах в сети, которые могут быть предоставлены сервером Samba.

Глобальный каталог

Для работы с глобальным каталогом, его необходимо установить согласно Руководству администратора Часть 1 - Обновление подсистем - 3.1.3. Обновление с установкой Глобального Каталога.

share_info.tdb Файл в директории /var/lib/samba в Samba представляет собой базу данных TDB, используемую для хранения информации о совместно используемых ресурсах (шарах) в Samba.

winbindd_cache.tdb Файл в директории /var/lib/samba в Samba представляет собой базу данных TDB, используемую для кэширования данных и запросов, выполняемых службой Winbind в рамках протокола аутентификации и авторизации в среде Samba.

winbindd_idmap.tdb Файл в директории /var/lib/samba в Samba представляет собой базу данных TDB, используемую для хранения информации о сопоставлении (маппинге) идентификаторов безопасности (SID) и POSIX UID/GID в процессе аутентификации и авторизации через Winbind.

Для просмотра содержимого файлов XXXX.tdb в Samba используется утилита tdbtool. Пример команды для просмотра содержимого registry.tdb:

tdbtool registry.tdb dump

На данный момент объекты из суб-доменов не синхронизируются в Global Catalog главного домена, как это сделано в Windows.

Глобальный каталог ALD Pro – это отдельный экземпляр LDAP-сервера, в котором содержится копия всех объектов домена в схеме данных Active Directory. Глобальный каталог обеспечивает возможность поиска объектов (пользователей и групп) из стандартных оснасток Windows, что нужно для добавления субъектов доверенного домена в списки доступа на стороне Windows.

Для более удобного просмотра всех настроек Samba, включая реестр, можно использовать команду net conf list

Команда net conf list в Samba используется для отображения текущей конфигурации Samba. Она выводит различные параметры и настройки, связанные с работой Samba, включая параметры глобальной секции smb.conf, информацию о доменах, настройки Kerberos и другие параметры.

Более подробную информацию о реестре можно найти по адресу

https://www.samba.org/~obnox/presentations/linux-kongress-2008/lk2008-obnox.pdf

Каждая служба устанавливает свой собственный уровень журнала отладки. Увеличение уровня журнала может предоставить больше информации о проблемах с Winbind, Samba(smbd) или nmbd

В Global Catalog попадают пользователи и группы только при наличии аттрибута ipaNTSecurityIdentifier, на основании которого генерируется аттрибут ObjectSid у объекта в Global Catalog.

Механизм поиска и добавления субъектов ALD Pro в списки ACL на стороне Windows работает следующим образом:

  1. Windows-администратор при добавлении пользователя/группы в ACL с помощью стандартной оснастки выполняет поиск объектов в доверенном домене ALD Pro. Запрос направляется к глобальному каталогу на порт 3268/TCP (LDAP) с аутентификацией по Kerberos. Если Kerberos-аутентификация по какой-либо причине не сработает (например, время в доменах отличается более, чем на 5 минут), то оснастка Windows попытается выполнить NTLM-аутентификацию, поэтому пользователь увидит окно для ввода учетных данных.

  2. После успешного поиска появится список объектов ALD Pro с отображением их uid (в случае пользователя) или cn (в случае группы).

  3. При добавлении субъекта в список доступа, система безопасности Windows выполнит еще один запрос к контроллеру домена ALD Pro по протоколу SMB для дополнительной проверки, существует ли субъект с таким SID в домене.

  4. Для успешного выполнения указанного запроса на контроллере ALD Pro должны работать службы smbd и winbind. Обработка запроса выполняется с использованием библиотеки ipasam (или aldprosam в случае доверительных отношений между доменами ALD Pro).

  5. После получения подтверждения, что субъект с указанным SID существует в домене ALD Pro, система Windows добавит его в редактируемый список доступа.

Настройка двусторонних доверительных отношений

Настройка и проверка перенаправления DNS ALD Pro

Для работы доверительных отношений с компьютеров из домена ALD.company.lan должны разрешаться имена компьютеров из домена WIN.company.lan и наоборот. Если этого нет, то нужно сделать взаимное перенаправление DNS-зон.

Настройка ALD Pro

Добавление зоны перенаправления можно сделать из графического интерфейса Роли и службы сайта → Служба разрешения имен → Перенаправление запросов.

  1. Имя зоны = имя домена MS AD;

  2. Глобальные перенаправители = IP-адрес контроллера домена MS AD, с которым устанавливаются доверительные отношения;

  3. Остальные поля и параметры оставить без изменений.

Настройка MS AD

Настройка контроллера домена MS AD осуществляется согласно официальным инструкциям к MS AD. (Пуск → Оснастка “DNS”):

  1. Контекстное меню к “Серверы условной пересылки” → Создать сервер условной пересылки;

  2. В поле “DNS-домен” ввести имя домена ALD Pro;

  3. Добавить IP-адрес контроллера домена ALD Pro в блоке “IP-адреса основных серверов:”.

Установка двусторонних доверительных отношений между доменами

  1. Так же можно интерактивно смотреть, что происходит с winbind в момент старта службы для этого выполните поочередно команды ниже:

systemctl stop  winbind.service
winbindd -i -d 100

  1. Если требуется повысить логирование только для определенного сервиса, в данном примере логирование включено «1» для всех сервисов, кроме winbind – для него включен уровень «100» . /etc/samba/smb.conf

../../../_images/image211.png 
smbcontrol winbind debuglevel
PID 26871: all:1 tdb:1 printdrivers:1 lanman:1 smb:1 rpc_parse:1 rpc_srv:1 rpc_cli:1 passdb:1 sam:1 auth:1 winbind:100 vfs:1 idmap:1 quota:1 acls:1 locking:1 msdfs:1 dmapi:1 registry:1 scavenger:1 dns:1 ldb:1 tevent:1 auth_audit:1 auth_
json_audit:1 kerberos:1 drs_repl:1 smb2:1 smb2_credits:1 dsdb_audit:1 dsdb_json_audit:1 dsdb_password_audit:1 dsdb_password_json_audit:1 dsdb_transaction_audit:1 dsdb_transaction_json_audit:1 dsdb_group_audit:1 dsdb_group_json_audit:1

Распространенные проблемы SSSD

Отсутствие групп при выполнении команды id

Проблема: нет групп при выполнении команды id username@FQDN_WindowsDomain или членов группы с getent group.

Решение. Проверить количество объектов в домене MS AD

# В Домене Active directory запустить Powershell и выполнить команду ниже
(Get-ADObject -Filter *).count

Проверить диапазоны идентификаторов пользователей домена MS AD:

# Для вывода списка доменных пользователей и их SID в домене Active Directory запустить Powershell и выполнить команду ниже
Get-ADUser -Filter * -Property SID | Select-Object Name, SID

Если количество объектов или последняя часть SID некоторых доменных пользователей MS AD превышает 200 000 – выполнить расширение диапазона:

#Показать текущие диапазоны (idrange) для всех доменов
# Произвести аутентификацию
kinit admin
#Вывести список доступных диапозонов
ipa idrange-find
#Изменить id_range для домена windomain.lan к примеру до 500 000
ipa idrange-mod WINDOMAIN.LAN_id_range --range-size=500000
#Удаление всего кеша с контроллера домена и перезапуск службы sssd
rm -f /var/lib/sss/db/* /var/lib/sss/mc/* && systemctl restart sssd

Долгое выполнение команды id

Отключение FAST аутентификации

Для доступа к ресурсам windows с аутентификацией по kerberos (IIS, cifs, принтеры с общим доступом по smb) необходимо отключить у клиентских компьютеров FAST аутентификацию, так как windows её не поддерживает. Для этого на всех клиентах ALD Pro, где предполагается доступ, необходимо настроить глобальную политику Групповые политики → Параметры компьютеров → Безопасность → FAST аутентификация. Выставить параметр never.

#Выполните команду id с параметром –G(вывести все ID групп)- эта каманда игнорирует вложенность групп
id -G  winuser@windomain.lan

#Если команда отрабатывает быстро то требуется добавить в существующую секцию в /etc/sssd/sssd.conf на каждом контроллере домена -игнорирование вложенных групп
[domain/alddomain.lan]
...
ignore_group_members = true
subdomain_inherit = ignore_group_members

#Выполнить очистку кеша и произвести перезапуск службы sssd
rm -f /var/lib/sss/db/* /var/lib/sss/mc/* && systemctl restart sssd

SSSD не удается подключиться к MS AD из-за ошибок с GSS-API

Проблема: поставщик удостоверений MS AD правильно настроен в файле sssd.conf, но SSSD не удается подключиться к нему с ошибками GSS-API.

Решение. SSSD может подключаться только к поставщику MS AD, используя его имя хоста. Если имя хоста не указано, SSSD-клиент не может разрешить IP-адрес хоста, и аутентификация завершается неудачей.

Например, при такой конфигурации:

[domain/ADEXAMPLE]
debug_level = 0xFFF0
id_provider = ad
ad_server = 172.16.0.1
ad_domain = example.com
krb5_canonicalize = False

SSSD-клиент возвращает этот сбой GSSAPI, и запрос аутентификации завершается неудачей:

(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Cannot determine realm for numeric host address)]

Чтобы избежать этой ошибки, необходимо установить для ad_server значение имени узла MS AD или использовать ключевое слово _srv_ для использования обнаружения службы DNS.

Распространенные проблемы DNS

ALD Pro (FreeIPA) использует BIND в качестве интегрированного DNS-сервера. Если есть подозрения, что с DNS что-то не так, необходимо проверить журналы, сгенерированные BIND.

journalctl -u bind9-pkcs11.service

Если требуется создать tcp dump, необходимо воспользоваться командой:

tcpdump -i eth0 -w /home/${USER}/$(date +%Y-%m-%d_%H-%M)_$(hostname).pcap
Распространенные проблемы DNS

№

Проблема

Решение

1

Не работает DNS resolving имен из новой подсети

Необходимо добавить новую подсеть в trusted_network на каждом контроллере домена ALD Pro (FreeIPA)

/etc/bind/ipa-ext.conf

Пример:

........................
acl "trusted_network" {
  localnets;
  localhost;
  192.168.88.0/24;
  172.19.3.0/24;
  172.19.4.0/24;
  <НОВАЯ Подсеть>;
};

2

Не работают рекурсивные запросы

Необходимо включить дополнительные опции на каждом контроллере домена ALD Pro (FreeIPA)

/etc/bind/ipa-options-ext.conf

Пример:

allow-recursion { trusted_network; };
allow-query-cache { trusted_network; };

Распространенные проблемы Trust Creation (Создание доверительных отношений)

Распространенные проблемы Trust Creation

№

Проблема

Решение

1

Ошибка 3221225485 при создании доверительных отношений:

ipa: ERROR: Ошибка обмена данными с сервером CIFS: код «3221225485», сообщение «An invalid parameter was passed to a service or function.» (оба значения могут быть «None»)

Проверить, что параметры реестра /var/lib/samba/registry.tdb – существуют и не были удалены. Для проверки выполнить команду net conf list. Если вывод пустой или есть увереность, что файл был поврежден, требуется повторно выполнить команду ipa-adtrust-instal, предварительно сделав копию файла конфигурацуии smb.conf cp smb.conf{,_bkp}, так как он будет перезаписан из шаблона.

Настройка производительности SSSD для крупных развертываний доверия

Настройка игнорирования участников групп (ignore_group_members)

Извлечение информации о пользователях (id <username@<ADdomain>) и группах является трудоемкой операцией для демона служб системной безопасности (SSSD), особенно при развертывании ALD Pro с доверием к большому домену MS AD. Улучшить производительность можно, настроив, какую информацию и как долго SSSD извлекает из поставщиков удостоверений (identity providers).

Предварительное требование

Необходимы права root для редактирования конфигурационного файла /etc/sssd/sssd.conf.

Процедура

  1. Открыть конфигурационный файл /etc/sssd/sssd.conf в текстовом редакторе.

  2. Добавить следующие параметры в раздел [домен] для домена MS AD. Если доменного раздела для домена MS AD еще нет, необходимо создать его.

[domain/ald.example.com]
ignore_group_members = true
subdomain_inherit = ignore_group_members
...

  1. Сохранить и закрыт файл /etc/sssd/sssd.conf на сервере.

  2. Перезапустить службу SSSD, чтобы загрузить изменения конфигурации.

systemctl restart sssd

ignore_group_members

Наиболее трудоемкой операцией является загрузка групп, включая их участников. Обычно на начальном этапе важно, членом каких групп является пользователь (id aduser@ad_domain), а не какие участники входят в конкретные группы (getent group adgroup@ad_domain). При установке для параметра ignore_group_members значения True, все группы отображаются как пустые, таким образом загружается только информация о самих объектах группы, а не об их членах, что обеспечивает значительное повышение производительности. Важно обратить внимание, что идентификатор aduser@ad_domain все равно вернет все правильные группы.

subdomain_inherit_inherit

Вышеуказанные параметры могут быть переданы в конфигурацию доверенных доменов MS AD. На данный момент единственным поддерживаемым методом является использование опции subdomain_inherit в разделе домена sssd.conf. Имена любого из двух приведенных выше параметров могут быть указаны в качестве значения subdomain_inherit, и они будут применяться как к основному домену (IPA), так и к поддомену MS AD.

Настройка таймаута конфигурации для плагина ipa-extdom на ALD Pro (FreeIPA)-серверах

Клиенты ALD Pro не могут напрямую получать информацию о пользователях и группах из MS AD, поэтому серверы ALD Pro используют плагин ipa-extdom для получения информации о пользователях и группах MS AD, и эта информация пересылается запрашивающему клиенту.

Плагин ipa-extdom отправляет запрос в SSSD на получение данных о пользователях MS AD. Если информации нет в кэше SSSD, SSSD запрашивает данные у контроллера домена MS AD (DC). Можно настроить значение таймаута конфигурации, которое определяет, как долго подключаемый модуль ipa-extdom ожидает ответа от SSSD, прежде чем подключаемый модуль отменит соединение и вернет вызывающей стороне сообщение об ошибке таймаута. Значение по умолчанию равно 10000 миллисекунд (10 секунд).

В следующем примере время ожидания настройки устанавливается равным 20 секундам (20000 миллисекунд).

Предупреждение

Необходимо соблюдать осторожность при настройке таймаута конфигурации:

Если задается слишком малое значение, например 500 миллисекунд, у SSSD может не хватить времени для ответа, и запросы всегда будут возвращать таймаут.

Если задается слишком большое значение, например 30000 миллисекунд (30 секунд), один запрос может заблокировать подключение к SSSD на этот промежуток времени. Поскольку только один поток может подключаться к SSSD одновременно, все остальные запросы от подключаемого модуля должны ждать.

Если ALD Pro-клиенты отправляют много запросов, они могут заблокировать все доступные рабочие процессы, настроенные для сервера каталогов на ALD Pro-сервере. Как следствие, сервер может быть не в состоянии ответить на какой-либо запрос в течение некоторого времени.

Изменять время ожидания конфигурации рекомендуется только в следующих ситуациях:

  • Если клиенты ALD Pro при запросе информации о пользователях и группах MS AD часто получают ошибки таймаута до истечения их собственного таймаута поиска. Значение таймаута конфигурации слишком мало.

  • Если сервер каталогов на ALD Pro-сервере часто блокируется, а утилита pstack сообщает, что многие или все рабочие потоки в это время обрабатывают запросы ipa-extdom. Значение слишком велико.

Предварительное требование

Пароль менеджера каталогов LDAP (LDAP Directory Manager password)

Процедура

Используется следующая команда, чтобы настроить время ожидания настройки на 20000 миллисекунд:

# ldapmodify -D "cn=directory manager" -W dn: cn=ipa_extdom_extop,cn=plugins,cn=config changetype: modify replace: ipaExtdomMaxNssTimeout ipaExtdomMaxNssTimeout: 20000

Настройка максимального размера буфера для плагина ipa-extdom на ALD Pro-серверах

Клиенты ALD Pro не могут напрямую получать информацию о пользователях и группах из MS AD, поэтому серверы IdM используют плагин ipa-extdom для получения информации о пользователях и группах MS AD, и эта информация пересылается запрашивающему клиенту.

Можно настроить максимальный размер буфера для плагина ipa-extdom, который регулирует размер буфера, в котором SSSD может хранить полученные данные. Если буфер слишком мал, SSSD возвращает ошибку ERANGE, и подключаемый модуль повторяет запрос с буфером большего размера. Размер буфера по умолчанию составляет 134217728 байт (128 МБ).

В следующем примере максимальный размер буфера устанавливается равным 256 МБ (268435456 байт).

Предварительное требование

Пароль менеджера каталогов LDAP (LDAP Directory Manager password)

Процедура

Используется следующая команда, чтобы установить максимальный размер буфера равным 268435456 байтам:

# ldapmodify -D "cn=directory manager" -W dn: cn=ipa_extdom_extop,cn=plugins,cn=config changetype: modify replace: ipaExtdomMaxNssBufSize ipaExtdomMaxNssBufSize: 268435456

Настройка максимального количества экземпляров для плагина ipa-extdom на ALD Pro-серверах

Поскольку клиенты ALD Pro не могут напрямую получать информацию о пользователях и группах из MS AD, серверы ALD Pro используют плагин ipa-extdom для получения информации о пользователях и группах MS AD, а затем пересылают эту информацию запрашивающему клиенту.

По умолчанию плагин ipa-extdom настроен на использование до 80% рабочих потоков LDAP для обработки запросов от ALD Pro-клиентов. Если служба SSSD на ALD Pro-клиенте запросила большой объем информации о пользователях и группах AD trust, эта операция может остановить службу LDAP, если она использует большинство потоков LDAP. Если данная проблема возникла, можно увидеть аналогичные ошибки в файле журнала SSSD для домена MS AD, /var/log/sssd/sssd__your-ad-domain-name.com_.log:

(2022-05-22  5:00:13): [be[ad.example.com]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed.
(2022-05-22  5:00:13): [be[ad.example.com]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed.
(2022-05-22  5:00:13): [be[ad.example.com]] [ipa_s2n_exop_done] (0x0040): ldap_extended_operation result: Server is busy(51), Too many extdom instances running.

Можно настроить максимальное количество экземпляров ipa-extdom, установив значение для параметра ipaExtdomMaxInstances, которое должно быть целым числом больше 0 и меньше общего числа рабочих потоков.

Предварительное требование

Пароль менеджера каталогов LDAP (LDAP Directory Manager password)

Процедура

  1. Извлечь общее количество рабочих потоков.

# ldapsearch -xLLLD cn=directory\ manager -W -b cn=config -s base nsslapd-threadnumber
Enter LDAP Password:
dn: cn=config
nsslapd-threadnumber: 16

Это означает, что текущее значение для ipaExtdomMaxInstances равно 13.

  1. Отрегулировать максимальное количество экземпляров. В этом примере значение изменяется на 14:

# ldapmodify -D "cn=directory manager" -W
dn: cn=ipa_extdom_extop,cn=plugins,cn=config
changetype: modify
replace: ipaExtdomMaxInstances
ipaExtdomMaxInstances: 14

  1. Следить за производительностью сервера каталогов ALD Pro и, если она не улучшится, повторить эту процедуру и отрегулировать значение переменной ipaExtdomMaxInstances.

Настройка SSSD в ALD Pro-клиентах для крупных доверительных развертываний IdM-AD

Эта процедура применяет параметры настройки к конфигурации службы SSSD в ALD Pro-клиенте, чтобы увеличить время отклика при получении информации из большой среды MS AD.

Предварительное требование

Нужны права root для редактирования конфигурационного файла /etc/sssd/sssd.conf.

Процедура

  1. Определить, сколько секунд занимает один незакешированный вход в систему.

а) Очистить кэш SSD на ALD Pro-клиенте client.example.com

Требуется предварительная установка apt install sssd-tools

[root@client ~]# sss_cache -E

  1. Измерить сколько времени требуется для входа в систему в качестве пользователя MS AD с помощью команды time. В этом примере из клиента ALD Pro client.example.com войти на тот же хост, что и пользователь ad-user из ad.example.com AD Domain

[root@client ~]# time ssh ad-user@ad.example.com@client.example.com

Ввести пароль как можно скорее.

Password:
Last login: Sat Jan 23 06:29:54 2021 from 10.0.2.15
[ad-user@ad.example.com@client ~]$

  1. Выйти из системы как можно скорее, чтобы отобразить прошедшее время. В этом примере один некэшированный вход в систему занимает около 9 секунд.

[ad-user@ad.example.com@client /]$ exit
logout
Connection to client.example.com closed.

real 0m8.755s
user    0m0.017s
sys     0m0.013s

  1. Открыть конфигурационный файл /etc/sssd/sssd.conf в текстовом редакторе.

  2. Добавить следующие параметры в раздел [домен] для домена MS AD. Установить параметры pam_id_timeout и krb5_auth_timeout на количество секунд, которое занимает некэшированная логика. Если доменного раздела для домена MS AD еще нет, создать его.

[domain/example.com/ad.example.com]
krb5_auth_timeout = 9
ldap_deref_threshold = 0
...

  1. Добавить следующую опцию в раздел [pam]:

[pam]
pam_id_timeout = 9

  1. Сохранить и закрыть файл /etc/sssd/sssd.conf на сервере.

  2. Перезапустить службу SSSD, чтобы загрузить изменения конфигурации.

systemctl restart sssd

Монтирование кэша SSSD в tmpfs

Демон служб системной безопасности (SSSD) постоянно записывает объекты LDAP в свой кэш. Эти внутренние транзакции SSSD записывают данные на диск, что намного медленнее, чем чтение и запись из оперативной памяти (RAM).

Чтобы повысить производительность, необходимо смонтировать кэш SSSD в оперативной памяти.

Кэшированная информация не сохраняется после перезагрузки, если кэш SSSD находится в оперативной памяти.

Это изменение безопасно выполнять на серверах ALD Pro, поскольку экземпляр SSSD на сервере ALD Pro не может потерять соединение с сервером каталогов на том же хосте.

Если выполнить эту настройку на ALD Pro-клиенте, и он потеряет подключение к серверам ALD Pro, пользователи не смогут пройти проверку подлинности после перезагрузки, пока не будет восстановлено подключение.

Предварительное требование

Нужны права root для редактирования файла конфигурации /etc/fstab.

Процедура

Довольно много времени, затрачиваемого на обработку запроса, уходит на запись объектов LDAP в кэш. Поскольку кэш поддерживает полные свойства ACID, он выполняет синхронизацию диска с каждой внутренней транзакцией SSSD, что приводит к записи данных на диск. С положительной стороны, это гарантирует, что кэш всегда доступен в случае сбоя сети и будет доступен для использования после сбоя компьютера, но, с другой стороны, запись данных требует времени. Можно смонтировать кэш на ramdisk, сократив затраты на ввод-вывод с диска, добавив в /etc/fstab в виде одной строки следующее:

tmpfs /var/lib/sss/db/ tmpfs size=300M,mode=0700,rootcontext=system_u:object_r:sssd_var_lib_t:s0 0 0

Затем необходимо подключить каталог и перезапустить sssd после этого:

mount /var/lib/sss/db/

systemctl restart sssd

Важно настроить параметр размера в соответствии с требуемым IPA и размером каталога объявлений. Как правило, можно использовать 100 Мб на 10000 записей LDAP.

Выполнение этого изменения на ALD-сервере немного безопаснее, чем на ALD-клиентах, поскольку экземпляр SSSD на сервере никогда не потеряет подключение к ALD-серверу, поэтому кэш всегда можно перестроить. Но в случае, если кэш был потерян после перезагрузки, и MS AD был недоступен из-за сетевой ошибки или аналогичного состояния, узел не смог бы вернуться к кэшированным данным о MS AD пользователях.

Плюсы: Операции ввода-вывода в кэше выполняются намного быстрее.

Минусы: Кэш не сохраняется при перезагрузках. Это означает, что кэш должен быть восстановлен после перезагрузки компьютера, но также и то, что cachedpassword теряются после перезагрузки.

Доступ пользователей ALD Pro к ресурсам MS AD

Создание сетевой папки в домене MS AD

Контроллер домена не рекомендуется использовать для создания общих сетевых ресурсов. Он используется в примере для упрощения процесса.

Создать папку C:\Common, в свойствах на закладке «Sharing» выбрать «Share» и в окне «Network access» выбрать «Share», оставив все по умолчанию.

../../../_images/image27.png

Если открыть окно «Common PropertiesSharingAdvanced SettingsPermissions», то будет видно, что по умолчанию на уровне SMB все пользователи имеют полные права.

../../../_images/image28.png

Но доступ к файлам регулируется также на уровне NTFS разрешений, которые настраиваются на вкладке «Common PropertiesSecurity». Можно предоставить доступ к общей папке всем аутентифицированным пользователям, и это позволит пользователям ALD Pro редактировать файлы в папке, доказывая работу доверительных отношений в направлении MS → ALD.

../../../_images/image29.png
../../../_images/image30.png
../../../_images/image311.png

Подключение сетевой папки на рабочей станции под управлением Astra Linux

Для подключения сетевой папки из домена MS AD в Astra Linux необходимо открыть проводник, кликнуть правой кнопкой мыши по узлу «Сеть» и выбрать команду «Новое место». Задать следующие параметры подключения:

В примере Windows Domain Controller именуется как dc-1.win.company.local

формат протокол://имя_сервера/название_общей_папки

../../../_images/image32.png

Необходимо обязательно проверить, что время на контроллерах MS AD и ALD Pro синхронизировано, т. к. для работы протокола Kerberos нужно, чтобы время всех участниках расходилось не более, чем на 5 минут.

Если нет необходимости настраивать прозрачную аутентификацию, то можно указать имя пользователя в формате:

#имя пользователя
ALD\admin
#в формате
ДОМЕН\имя_пользователя

Система предложит сохранить учетные данные в связке ключей, для работы с которой можно воспользоваться приложением seahorse «Пароли и ключи»

# apt-get install seahorse
# seahorse
../../../_images/image33.png

Ограничение доступа по SID

Сценарий, когда доступ к сетевому ресурсу предоставляется всем пользователям домена, является крайне редким. На практике обычно требуется предоставить доступ только строго ограниченной группе пользователей. Если воспользоваться окном «Select Users or Groups», можно обнаружить, что объекты доверенного домена ALD Pro найти не удается.

../../../_images/image34.png

Стандартный механизм поиска объектов из доверенного домена работает через глобальный каталог, которого в обычной FreeIPA нет. Глобальный каталог – это еще один LDAP-каталог, который должен быть доступен на порту 3268 и предоставлять данные обо всех объектах леса в определенной схеме данных. Не имея этой службы на стороне FreeIPA, доступ конкретным пользователям можно предоставить только по SID через PowerShell.

Посмотреть SID пользователя ALD Pro можно с помощью утилиты wbinfo на ALD Pro контроллере домена:

Используя wbinfo

root@aldpro01:~# wbinfo -n 'ald\admin'
S-1-5-21-896088827-1417987318-1335504985-500 SID_USER (1)

Используя ipa command

root@ald01:~# ipa user-show admin --all | grep ipantsecurityidentifier
ipantsecurityidentifier: S-1-5-21-896088827-1417987318-1335504985-500

Назначить права доступа можно командой ICACLS (Integrity Control Access Control List)

Наиболее популярные разрешения:

r = чтение

rx = Чтение, Выполнение, Список содержимого папки

rxm = Чтение, Выполнение, Список содержимого папки, Запись, Изменение

f = Полный доступ

(OI) = Для этой папки и её файлов

  1. = Для этой папки и её подпапок

Таким образом, чтобы дать обычные права на чтение и запись на папку, используются разрешения (OI)(CI)rxm. Тогда команда будет выглядеть так:

PS C:\Users\Administrator> ICACLS "C:\Temp" /grant "*S-1-5-21-896088827-1417987318-1335504985-500:(OI)(CI)rxm"

После добавления объектов в ACL, в стандартном окне безопасности они будут отображаться даже не по своим SID, а по привычным именам, т. к. для разрешения имен глобальный каталог не требуется.

Для упрощения администрирования в MS AD можно создать вспомогательные группы. Например, для администраторов ALD Pro в MS AD создается группа «WINALD_Pro_Administrators», в эту группу добавляются SID группы «ALDAdmins» из доверенного домена ALD Pro. Далее при назначении прав доступа на общий сетевой ресурс можно будет использовать группу «WINALD_Pro_Administrators».

Добавление пользователей и групп из ALD Pro домена в домен MS AD

Процесс добавления пользователей из одного домена в другой осуществляется через доверительные отношения между доменами. По умолчанию в доверенных доменах MS AD используется Global Catalog для поиска пользователя или группы, однако ALD Pro версии ниже 2.0.0 по умолчанию не имеет глобальный каталог, по этой причине для добавления пользователя или группы из домена без глобального каталога в домен MS AD с глобальным каталогом, используется PowerShell скрипт.

При добавлении пользователя или группы в домене MS AD будет создан специальный объект Foreign Security Principal.

https://social.technet.microsoft.com/wiki/contents/articles/51367.active-directory-foreign-security-principals-and-special-identities.aspx#:~:text=A%20Foreign%20Security%20Principal%20(FSP,security%20groups%20and%20granted%20permissions.

Порядок добавления пользователя или группы

  1. Посмотреть SID пользователя ALD Pro можно с помощью утилиты ldapsearch:

root@aldpro01:~# wbinfo -n 'ald\elena.kuznetsova'
S-1-5-21-1784717832-1844364183-3442789864-1013 SID_USER (1)

  1. На стороне MS AD необходимо создать Domain Local группу, куда можно добавит SID из домена ALD Pro

../../../_images/image35.png

  1. На стороне MS AD на контроллере домена необходимо запустить скрипт

    <S-1-5-21-1784717832-1844364183-3442789864-1013>– SID пользователя или группы

    <CN=Contoso-Group-DL,CN=Users,DC=contoso,DC=dom >- Distinguished Name группы

#SID Из леса ALD_Pro(Пользователь или группа)
$AldSid = 'S-1-5-21-1784717832-1844364183-3442789864-1013'

#Domain Local Group из леса Active Directory
$DomainLocalGroupDN = 'CN=Contoso-Group-DL,CN=Users,DC=contoso,DC=dom'

#Создание нового Directory Entry
$group = New-Object DirectoryServices.DirectoryEntry("LDAP://$($DomainLocalGroupDN)")

#Добавление AldSid в DomainLocal группу
[void]$group.member.Add("<SID=$AldSid>")
$group.CommitChanges()
$group.Close()

После выполнения скрипта пользователь будет добавлен в группу и соответствующий объект Foreign Security Principal будет создан автоматически.

Теперь можно назначить Domain Local группу, к примеру, на файловые ресурсы, и все пользователи или группы внутри нее будут иметь доступ к ресурсу в домене MS AD.

../../../_images/image36.png
../../../_images/image37.png

Доступ пользователей MS Windows к ресурсам ALD Pro

Доступ к ресурсам ALD Pro пользователям из доверенного домена MS AD предоставляется через внешние группы.

На стороне ALD Pro пользователям из доверенного домена MS AD предоставляется доступ к ресурсам через внешние группы.

# ipa group-add 'ad_administrators_external' --desc='Внешняя группа администраторов из MS AD' --external
# ipa -n group-add-member 'ad_administrators_external' --external 'WIN.COMPANY.LOCAL\Domain Admins'

Внешние группы не имеют gid (являются не POSIX-группами), поэтому их нельзя использовать напрямую для предоставления доступа к сетевым файлам. Следует создать еще одну обычную POSIX-группу и включить в нее группу ad_administrators.

Важно отметить, что добавление двустороннего доверия возможно в обычной инсталляции FreeIPA, даже не имея поддержки глобального каталога.

Установка глобального каталога (в ALD Pro 2.0.0)

Склонировать репозиторий:

# git clone --branch AD-39377-mvp1 https://git.astralinux.ru/scm/ad/aldpro-backend-global-catalog.git /opt/gc/

где

  • git clone – команда для клонирования репозитория

  • AD-39377-mvp1 – имя ветки, в которой содержатся необходимые исходные коды

  • https://git.astralinux.ru/… – адрес репозитория с кодом глобального каталога

  • /opt/gc/ - имя папки, в которую нужно клонировать репозиторий

Запустить скрипт, который выполнит настройку глобального каталога в системе:

# /opt/gc/ipa-gc-install.py --gc-cert-file /etc/ssl/freeipa/server.p12 --gc-pin 'AstraLinux_172' --disable-fast-preauth

где

  • ipa-gc-install.py — имя файла со скриптом для настройки GC

  • server.p12 — контейнер с сертификатом удостоверяющего центра и сервера